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Field of the Invention 

The present invention is in the area of services provided by service 
suppliers, pertaining generally to methods and apparatus for marketing 
services that may be reserved by customers through a variety of 
communication systems and interfaces, and more particularly to methods for 
forming and expressing reservables and engagements in a database of a 
transaction service. 



Cross-Reference to related Documents 

The present invention is a divisional of US patent application S/N 
09/594,419, filed 6/14/2000 and entitled "Methods and Apparatus for 
Marketing Reservable Services", disclosure of which is included herein in its 
entirety by reference. 

Background of the Invention 

The phenomenal growth of the public network known as the Internet 
is notoriously well-known at the time of the present patent appHcation. This 
growth has been, and continues to be, in the sheer number of the end-users. 



in the number and diversity of hosting enterprises providing information and 
services to the users, and in the quantity and quality of equipment and 
interconnections making out the physical presence of the Internet. 

The phenomenon of the Internet network motivates continuing 
development in every aspect. End-user equipment and software is evolving 
at a rapid rate, bringing more versatile Internet capable appliances, for 
example. Means for and bandwidth of connections are evolving as well, as is 
the capability of data transfer systems, such as routers in the network. 

Another area of significant development in the Internet world is in 
services provided by enterprises hosting service centers on the Internet. 
There have been hundreds of new, and in many cases innovative business 
models, or new ways of doing business. The present invention, in many 
aspects, is in this technology category. 

The presence, growth, and development of the Internet is a 
communication phenomenon. The Internet is providing new, better, and 
faster means of communication. Because all human transactions, being 
agreements reached between persons after consideration of alternatives, are 
reached through communication, the Internet offers great new opportunities 
for enhancing transactions and their dynamics. All businesses advertise and 
sell either or both products and services. The present invention, and various 
embodiments, deals with service transactions. 

The record of the development of the Internet is a record of 
expanding ways in which those who have services to sell can offer and 
transact those services to the Internet-connected world. At the time of the 
present patent application, there are already many Internet systems in place 
for offering and contracting services. Also, in most cases, the services 
offered our reservable; that is, one may contract to purchase such a service 
at a particular place and at a particular time. Some enterprises, for example, 



allow people to reserve tables at various restaurants on specific dates and at 
specific times. Others allow golf enthusiasts to reserve tee-times at various 
golf courses. All such systems advance consumer facility in at least a small 
way. Still, a great number of individual sites, each offering one or a few 
related services, creates a maze of difficulty for the Internet consumer. 

In addition to the problems addressed in the above paragraphs, 
database entries reflecting time-based resources are typically not created nor 
managed in a very efficient manner. For example, sellable resources are 
typically listed separately from sold resources wherein no efficient cross- 
referencing exists or such cross-referencing must be manually managed. 
Similarly, searches performed in such a database are not managed in a most 
efficient manner. If there are a variety of resources to select from, all of 
those resources will typically be searched in order to extract those resources 
matching a much narrower search parameter. 

In a transaction database handling both sellable resources and 
engaged resources wherein both entities are time-based, micro management 
techniques must be employed in order to successfully convert status 
indication from sellable resource to engaged resource over the entire 
database. For example, as available time allotted for a sellable service is 
used up through engagement of the service, exact status must be available at 
any given time. In prior art management techniques, human resources are 
employed to perform periodic updating through data entry and other manual 
data management techniques such as deleting a reserved portion of a sellable 
resource from the database and creating a new engagement status, which 
occupies the subtracted time span. 

When a single database is used to keep track of a plurality of 
disparate resources and engagements thereof, induction of human resource 
for micro-management purposes can lend to an unacceptable level of system 



errors such as double booking, incorrect evaluation of time units, and other 
typical mismanagement problems. 

What is clearly needed is a method for calculating and representing 
available and engaged resources represented in a single transaction database 
handling a plurality of disparate resources such that the states of resources 
left over after engagement of those resources and the states of engagements 
of those resources or a portion thereof, may be indicated correctly in real 
time as activity occurs. 

Summary of the Invention 

In a transaction system, a data entity describing a reservable service 
(reservable) as recurring intervals in a span of time (time-span) is provided. 
The entity described as a reservable comprises an indication of the time-span 
nature of the entity; an indication of the service offered; an indication of a 
time period redundancy in the time-span; and an indication of the occurrence 
of the interval in each redundancy time period. The entity described as a 
reservable is, in preferred aspects, one of two variables in an algebraic 
fiinction for determining a state of engagement of all or a portion of the 
entity. 

In a preferred aspect, the data entity is expressed in the form of 
Extensible Markup Language (XML). In another aspect, the data entity may 
expressed in the form of one of a class of SGML-based languages including 
XML. The indication of a time-period redundancy for the entity described 
as a reservable comprises one of hourly, daily, weekly, monthly, yearly, 
weekdays, or weekends. In another aspect, redundancy is defined by 
exclusion. Also in one aspect, the entity described as a reservable fijrther 



comprises an indication of one or both of a supplier or a resource associated 
with the supplier. In one aspect, the entity once formed may be subsequently 
divided into a plurality of data entities as a result of the algebraic 
computation. 

In the same transaction system, a data entity describing an engaged 
service or portion thereof (engagement) as a discrete time-based entity is 
provided. The entity described as an engagement comprises an indication of 
the engagement nature of the entity; an indication of the service to be 
performed; an indication of a start and end time for the engagement; and an 
indication of a date for consummation of the engagement. The entity 
described as an engagement is, in preferred aspects expressed as a result of 
algebraic computation between two variables in an algebraic function for 
determining a state of engagement of all or a portion of the entity described 
as a reservable. 

In a preferred aspect, the data entity described as an engagement 
further comprises an indication of a customer scheduled to receive the 
sen/ice and one or both of a resource or a supplier scheduled to provide the 
service. In a preferred embodiment, the entity is expressed in the form of 
Extensible Markup Language (XML). However, in another embodiment, 
the entity is expressed in the form of one of a class of SGML-based 
languages including XML. 

In the same transaction system, a data entity describing a request for 
service is provided. The entity described as a request for service comprises 
an indication of the service requested; an identification of the requesting 
party; and an indication of a date and time for the service to be performed. 
In preferred aspects, the data entity described as a request for service is one 
of two variables in an algebraic function for determining a state of 
engagement of ail or a portion of the entity described as a reservable. 



In a preferred aspect, the entity described as a service request is 
expressed in the form of Extensible Markup Language (XML). However, in 
another aspect the entity may be expressed in the form of one of a class of 
SGML-based languages including XML. In one aspect, the entity described 
as a service request includes an indication of an expected price. 

In another aspect of the invention, in a transaction system, a defined 
Extensible Markup Language (XML) algebra is provided. The algebra 
comprises a first XML time-span expression describing a reservable service 
(reservable) expressed as intervals in a timeline; a second XML expression 
describing a requested service (request), including a desired date and time 
and XML operators for processing the first and second XML expressions to 
produce new XML expressions. 

In a preferred aspect, one of the operators includes an Intersect 
operator for comparing the first and second XML expressions, determining 
presence of a valid Intersection, meaning that the first XML expression 
(reservable) completely overlaps in time the second XML expression 
(request), indicating that the reservable is a candidate to fulfill the request. 

According to a variant of the preferred aspect described above, the 
first XML expression has a Start time point, and the operators include a 
Smear operator which fimctions to alter the first XML expression by 
extending the Start time by a specified amount. According to other variants 
of the preferred aspect, the operators include a Translate operator that 
fiinctions to translate the first XML expression either forward or backward 
in time. 

The operators according to a preferred aspect, also include a Union 
operator that functions to return a union of two first XML time-span 
expressions defining two different time-spans; a Subtract operator that 
functions to subtract a first time-span XML expression from another time- 
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span XML expression, returning a time-span XML expression of the 
difference; and an Inverse operator that functions to return the Inverse of a 
given time-span XML expression; a Sizefilter operator that functions to filter 
out of a time-span XML expression all spans that are smaller than a specified 
5 duration; and a Sizefilter operator that functions to represent a reference to a 
second time-span XML expression from a first time-span XML expression. 
All of the variants of the preferred aspect may be caused to function 
collectively or separately during given computations performed on the 
entities within the transaction database depending in part on the nature of the 
10 entities. 

In still another aspect of the present invention, a method for 
matching reservable services (reservables) with requests for service 
(requests) in a transaction system is provided. The method comprises the 
steps of (a) representing reservables as time intervals in a time-span 

15 expressed in an Extensible Markup Language expression, and storing the 

reservables in a database; (b) eliciting from a customer a request as an XML 
expression including a desired date and time and (c) searching the database 
for intersections between reservables and the request to present candidate 
reservable services to the customer. 

20 In one aspect of the method, a further step is provided for creating an 

XML engagement expression (engagement) from the intersection of a 
reservable and a request expression, wherein the engagement expression 
defines a service to be performed for the customer at a specified time and 
place. 

25 In the embodiments of the invention taught in enabling detail herein, 

for the first time a dynamic method is provided for managing and creating 
time-based entities in a transaction database that greatly reduces the need for 



micro management performed by virtue of human resource and sharply 
reduces associated errors resulting from mismanagement. 



Brief Description of the Drawing Figures 

Fig. 1 is a schematic diagram of a reservables transaction system 
according to an embodiment of the present invention. 

Fie. 2 is a block diagram of data organization and inter-relationships 
in a preferred embodiment of the present invention. 

Fig. 3 is a schematic diagram illustrating supplier communication 
with the system in an embodiment of the invention. 

Fig. 4a is a diagrammatical representation of system data entities 
according to a preferred embodiment of the present invention. 

Fig. 4b is a diagrammatical representation of system data entities 
according to an alternative embodiment of the present invention. 

Fig. 5 is an illustration of a six-week time window applied to the 
system data base. 

Fig 6 is a flow diagram illustrating an exemplary transaction process 
in an embodiment of the present invention. 



Description of the Preferred Embodiments 



Overview 
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In a preferred embodiment of the present intention, an Internet- 
connected system is provided wherein a very large number of typically small 
businesses may offer reservable services to an even greater number of 
Internet-connected consumers/clients. The invention is not limited, 
5 however, to small businesses, and applies in many embodiments to enterprise 
aggregates of a plurality of businesses or service providers. The number of 
clients (customers) is virtually unlimited, as practically everyone has, or may 
gain access to communication tools to interact with services of the invention. 
The number and types of businesses and aggregated enterprises which might 

10 participate in such a model is also essentially unlimited. 

The present inventors have developed a unique system and model for 
facilitating transactions among such businesses and clients. In this system, a 
service provider may participate if the services offered can be presented to 
potential clients as time-associated reservable entities. The present inventors 

15 term such service entities as reservables, and this terra is used throughout 
the present patent application. 



Reservables 

A few specific examples will clarify what the inventors mean by 
reservables. Beauty salons, considered as a class of service suppliers, will all 
typically employ hair stylists, that is persons with the skill and training (and 
perhaps licensing as well) to do hair styling. All hair stylists also may be 
considered to offer services within a certain broad definition of hairstyling 
services, including such as hair washing, permanents, and the like, and such 
services may be considered to typically endure for certain time durations. 
There are therefore global definitions that may be made for hairstyling 
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services. A particular salon, in a particular locale, however, will employ a 
specific group of persons for performing hair styling services, and each of 
these persons will have an individual set of skills, and an individual matrix of 
availability. As a concrete example, Miranda Chavez may be employed by 
XStream Hair Salon in San Mateo, CA, and she may offer (through her 
employer at the supplier's place of business) hairstyling within a specific class 
of styles, each session to consume a time duration of 90 minutes, and priced 
at $35 per session. 

Given the above discussion of general service and particular services 
relative to resources, a reservable for the purposes of the present 
specification, is at the most particular level: A reservable will appear in the 
database of the system of the invention as, for example, a Miranda Chavez 
styling session, with its attendant constraints on time, nature of service, and 
price. And is differentiated specifically from a Barbara Turner styling 
session, which might appear as a reservable in the database, having a 
different duration, applying to different hair styles, and at a different price, 
even though Barbara Turner may be employed by the same supplier. 

Further to the above, Miranda Chavez may be multi-talented, and 
enabled by skill set, license, and whatever else might be required, to do 
pedicures as well as hair styling. In this case there may well be reservables in 
the database, constrained particularly to Miranda, having a duration, a 
description of service content, and a price, for pedicures. By virtue of two 
different reservables, Miranda may be engagable for any one of several 
services in the same or overlapping time durations. The system of the 
invention is required, as customers engage services (make reservations), to 
amend the inventory of reservables accordingly. That is, when Miranda is 
engaged for a pedicure from 2:00 to 3:00 PM on a particular afl:ernoon, she 
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will no longer be available to do hair styling in that time frame, and the 
system has to amend the inventory of reservables to suit. 

In some cases reservables assume another dimension, that of 
capacity. Consider a movie house, for example. A reservable for the Bijou 
theatre may be for a performance of Batman III from 2:00 PM to 5:30 PM 
on Sunday June 4th. The theatre seats 75, so the reservable has the 
dimension of capacity. The reservable continues to be available for 
engagement until 75 persons have signed up for the performance (bought 
tickets, or engaged to buy tickets). More detail is provided below regarding 
reservables, and how they are generated and managed in the system of the 
invention. 

In a preferred embodiment of the present invention a reservable has 
new and unique characteristics. In conventional systems an enterprise may 
provide, through the Internet, for example, a service making reservations for 
the particular enterprise. There is always a strict relationship between the 
supplier providing the service and the customer contracting for the service. 
In one preferred embodiment of the present invention reservables are defined 
independent of suppliers: reservables can be defined, within the common 
framework of the inventors' exchange, to capture the characteristics of a 
broad range of businesses and the services they provide. One feature of the 
present invention that makes this characteristic possible and even desirable is 
the exchange nature of the system of the present invention. Over a large 
number of suppliers of various services, and at least an equally large number 
of potential customers for such services, the inventors have discovered that 
there is an opportunity to define and market salable services (reservables) 
essentially independent of suppliers. 

A fijrther example may help to clarify the nature of supplier- 
independent reservables. Assume, for example, that a relatively large 
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number of suppliers of automotive services in a particular defined geographic 
region all have mechanics trained to do oil changes, and therefore offer oil 
changes as reservables. . If there are several suppliers who meet the 
requirements of this reservable, and the constraints in the reservables are 
very close in nature, then the service may be offered completely 
independently of specific suppliers. Under these circumstances a potential 
client or customer comes to the exchange with a desire to make an 
appointment for an oil change within the bounds of a particular geographic 
region. The exchange presents to the potential customer from the database 
of reservables available to the system, and perhaps several options pertaining 
to location, price, and so forth, and potential customer must make a decision 
as to whether to contract for the service or not. 

There are other unique characteristics of reservables: For example, a 
reservable in a preferred embodiment of the present invention may be 
embodied as a semi-continuous representation of the time interval over 
which the corresponding service is offered (available). For example, a 
particular barber's schedule on an "open" day (no reservations yet made) 
might be represented by a single reservable time interval from 10am to 5pm 
(the barber's hours). Note that a reservable is represented in a time interval, 
rather than a time span. An essential difference is that a time interval is 
finite, having a specific start and end time, while a fime span is potentially 
infinite. A specific service request from a potential customer might at some 
point be accommodated for a haircut, matching all of the criteria for this 
particular barber, including a desire to have this haircut take place within the 
time interval representing the barber's reservable. An engagement 
transaction is made, and a new database entity is created for the engagement, 
including the customer, the supplier, the time, the price, and so on. 
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Now the system must recalculate (regenerate) the reservable 
inventory. The time and duration for the engagement is no longer available 
as a reservable for the particular barber. Let us assume the engagement 
made is for a haircut at 2:00 PM to last 1 hour (to 3:00 PM). The 10:00 
AM to 5:00 PM interval as a reservable for this barber now becomes two 
intervals; one from 10:0 AM to 2:00 PM, and the other from 3:00 PM to 
5:00 PM. 

This implementation differs from systems which use discrete 
representations of service availability: for instance, the barber's availability 
might be represented by 14 "bins", each 30 minutes in length, end-to-end, 
running from 10am to 5pm. 

Some of the advantages of the new approach are: 1. speed of lookup 
(fewer reservables to consider), 2. flexibility and efficiency (no need to 
decide ahead of time how time should be broken up, more opportunity for 
optimization/filling gaps), 3. accuracy (can accommodate to-the-miUisecond 
"granularity", which would be impossible to represent in reasonable 
space/time with a discrete system which would have to generate 25,200,000 
milUsecond-long bins for this single 7-hour day). 

This is not to say that the instant invention is limited to the kinds of 
time interval reservables defined immediately above. In the instant invention 
discrete reservables may be used instead of, or in conjunction with interval, 
reservables, and, in some cases, reservables may be created on-the-fly as 
requests are made. 

The services hierarchy, to which reservables are associated, is 
important as it helps to enable search features that are described above. The 
services hierarchy is in general a system for classifying services by type and 
region. For example, there may be a high-level category for automotive 
repair services, which is subdivided at a lower level into top and body repair, 
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engine repair, transmission repair and replacement, lubrication services, and 
so on. Individual ones of these lower-level categories may be further divided 
into a more granular matrix. Engine repair, for example, can be further 
categorized into foreign and domestic models. Although reservables 
may be, in special cases, supplier-independent, they can also be extended to 
capture particular properties for some suppliers. For instance, reservables 
might have a notion of "capacity" to represent a movie (for example): each 
ticket sold to the movie would decrement 1 unit of capacity from the 
reservable, until it's capacity reached 0. The dimension of capacity in 
reservables extends to many cases, such as restaurants (# of tables and 
seats), theatres and the like, and to any situation where more than a single 
customer may be acconunodated in a service simultaneously. 

Engaged Reservable (Engagement) 

Aji engagement, in a preferred embodiment of the present invention, 
is in many cases quite similar to what is commonly known as a reservation. 
In this sense, a customer, taking advantage of the system to arrange for a 
service to be performed, after some negotiation with the system, transacts 
with the system to engage, or reserve, a service to be performed at a 
particular time and place, and typically at a particular price. In most cases 
the engagement is supplier-specific; that is, the customer transacts to receive 
a service to be performed by a resource associated with a particular supplier. . 
As an example, a barbershop may have several barbers (resources) available 
to do haircuts at particular times, and the customer, in the transaction, 
agrees to receive a haircut from one of the barbers at a particular time, on a 
particular date, at a particular price at a particular place, usually the premises 
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of the barbershop (but certainly not always so). In some cases, for example, 
the barber service may specialize in outservice haircuts, and the barber will 
come to the location of the customer to perform the service. 

Following the concept of supplier-independent reservables in one 
preferred embodiment, engagements may also be supplier-independent. That 
is, a customer, visiting the service exchange in an embodiment of the present 
invention, may engage a reservable without being matched with a specific 
resource or supplier. This is quite different from a conventional reservation, 
because, at the time of contracting for the reservable, the customer does not 
know where and how to take delivery of the service contracted, that is, the 
engagement. In this interesting case, the enterprise hosting the exchange has 
an option over a reasonable time window of selecting among several 
suppliers having resources capable of fulfilling the requirements of the 
engagement, and even of soliciting suppliers to fijlfili engagements already 
made. Further examples of such supplier-independent reservables and 
engagements are described in more detail below. 

System Architecture 

Fig, 1 is a schematic diagram of a system according to a preferred 
embodiment of the present invention. Fig. 1 illustrates a client station 1 1 
having a personal computer (PC) 13 and a telephone 15. A personal- 
computer such as PC 13 in a home is a typical way in which a person may 
access and browse the Internet. The skilled artisan will recognize and 
understand that such a PC is but one of many ways a client may access the 
Internet network. At the time of the present patent application there is rapid 
growth in the use of handheld devices for Internet access. Such devices 
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include personal organizers, cellular telephones, handheld computers, and 
several other devices. PC 13 in Fig.l is therefore meant to represent all of 
the many Internet appliances that may be used to access and browse the 
Internet, except the case of Internet access by cellular telephone, which is 
represented in Fig. 1 by telephone 20 acting through interface 22.. 

PC 13 is shown as connecting through an Internet service provider 
(ISP) 17 to the Internet network represented by cloud 3 1 . The skilled 
artisan will also recognize that there are a number of ways that Internet 
appliances may connect to the Internet network. Computerized televisions, 
WEB TV, for example, may connect through cable modem. Some handheld 
devices are now available that connect in a wireless fashion. Cellular 
telephones always connect, if Internet-enabled, wirelessly. Also, devices 
connecting by telephone modem may do so through a standard analog line, 
and integrated services digital network (ISDN) line, or a high-speed digital 
services line (DSL). The connection of PC 13 to Internet cloud 3 1 through 
ISP 17 is therefore meant to represent all of the conventional ways Internet 
appliances may connect to the Internet. 

Backbone 19 shown in Internet 3 1 is meant to represent all of the 
interconnectivity in the Internet. Two servers, server 21 and server 25 
represent the great number of Internet connected servers that are accessible 
by the public. A particular transaction server 23 is hosted by an enterprise 
providing reservable transaction services according to an embodiment of the 
present invention. Transaction server 23 has access to a data repository 27, 
which, in a preferred embodiment, contains a sophisticated database 
according to embodiment of the present invention. Transaction server 23 
also is enhanced by a software suite 29, which represents unique software 
according to embodiments of the present invention. 
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Client station 1 l.in Fig. 1 also is shown as having a telephone 15 
which connects to a public switched telephone network (PSTN) 33. 
Telephone 15 is capable of reaching all destinations in PSTN 33, including 
an interactive voice response (IVR) system 35, which, in the embodiment 
described with reference to Fig. l,is associated with transaction server 23, 
and hosted by the same enterprise that hosts transaction server 23. IVR 35 
is shown as connected to transaction server 23 by a communication link 37. 
The skilled artisan will recognize that there are a number ways this 
communication may take place. Link 37 may be an optical link, a high-speed 
land-line, a wireless link, or the link may be accomphshed by a (typically 
secure) Internet connection to backbone 19. There are a variety of 
possibilities. Unique functionality of the system including transaction server 
23 and IVR 35 is described in plural aspects and in enabling detail below. 

In addition to the above, access to server 23 may also be made by 
cellular telephone. A single cellular telephone 20 is illustrated in Fig. 1 as 
connecting wirelessly to a cellular interface 22, connecting conventionally to 
PSTN 33. The skilled artisan will be aware that block 22 represents all off 
the equipment and connections that are known in the art for communication 
by cellular telephone. Also that the single telephone 20 represents the ability . 
of customers and suppliers to interact with the system of the invention by 
cellular telephone. 

Also shown in Fig. 1 is a supplier station 12, quite similar to client 
station 1 1. A supplier, in a preferred embodiment of the present invention, is 
quite different from a customer. The supplier, for example, is typically a 
small business that contracts with the hosting enterprise to offer services as 
reservables. The means by which a supplier communicates with the 
exchange hosted on server 23, however, is essentially the same as the means 
by which customers communicate with the exchange. In Fig. I supplier 
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station 12 is equipped with a PC 14 connecting via modem through an ISP 
to Internet baclcbone 19 and thence to server 23. Station 12 represents all 
suppliers contracting with the service at server 23. Supplier station 12 also 
has a telephone 16 connecting to PSTN 33. It will be apparent to the. skilled 
artisan that the arrangement shown is exemplary, and supplier 
communication with server 23 might be accomplished in a variety of other 
ways. 

Data Structures and Interconnectivitv 

Fig. 2 is a block diagram of data structures and interrelationships in a 
preferred embodiment of the present invention. The database structure in 
preferred embodiments of the present invention is unique in that inventory 
which is added and marketed through the transaction service by service 
suppliers is defined and organized as reservable entities. In general a 
resen/able is a data record defining a capability for performing a specific 
service by a specific resource over a particular time interval, as described 
above. The present Inventors are aware that database operations are not 
particularly efficient when looking for enfities that do not exist (their non- 
existence can only be determined by examining the result of inverting all 
positive entities). In a conventional operation providing reservations to 
clients or customers, the positive entities are the scheduled reservations or 
appointments, rather than those potential appointment not yet made. Yet it 
is a potential appointment not yet made that a customer will be shopping for, 
and thus that the database will be searching for. The Inventors have solved 
this efficiency problem by defining the salable inventory as positive data 
structures called reservables, separate from reservations. At the point that a 
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customer contracts to purchase a reservable, that reservable becomes an 
engagement (a reservation) (a "negative" entity). 

As described briefly above, the system of the present invention in one 
preferred embodiment, embodied in one or more transaction servers, such as 
server 23 of Fig. 1, functions as an exchange between service suppHers and 
customers for the services supplied. In this aspect there would be many 
suppliers of services and many customers. In another aspect of the invention 
the system could be hosted and operated by a single host/supplier, such as a 
company like Midas, which markets services in automotive areas, such as 
exchanging old mufflers for new; or by a company like Budget, which 
provides rental cars for which customers make reservations. This single 
business might offer many geographically disparate service providers to 
customers, each representing individual members of its franchise or chain, 
and each may operate with varying degrees of autonomy (both within the 
system and in its actual business practices). 

The present inventors, in developing the system of the invention in 
preferred embodiments have provided numerous innovative structures and 
techniques, many of which, in alternative embodiments, may be provided as 
separate and unique business-to-business services. These innovative 
structures and techniques are described in enabling detail herein and below. , 

Referring now to Fig. 2, as an overview of the database in a 
preferred embodiment of the present invention, organized by data structures, 
reservables 39 represent the inventory of time-based entities (services) 
offered for reservation and sale, as described above. Reservables are 
calculated (instantiated) by a unique time-line algebra in preferred 
embodiments of the invention, from unions and intersections of other data 
structures, in particular from such as resources, supphers, resource 
capabilities (skill sets), and service definitions. Specific suppliers having 
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certain fixed and variable resources may contract with the exchange in a 
preferred embodiment of the present invention. The suppliers contracting 
with the exchange are listed and identified as data structures 41, labeled 
suppliers. Typically, each contracting supplier is identified by such 
characteristics as full name, at least one address, city, state or province, a 
country code, a postal code, a vertical key, determining to which vertical 
services industry the supplier's business may be classified, a region key, 
determining the geographic region of the supplier, certain other properties, 
and a flag for availability. Data structure 41 identifying suppliers is 
implemented in the database in a formal manner in which some, but perhaps 
not all, of the characteristics described may be required. In some 
embodiments, as described above, there may be but a single supplier to 
whom all resources are associated. 

Another data entity and structure defined and useful in a preferred 
embodiment of the present invention is that of a resource, recorded in data 
structure 43. A resource differs from a suppher in that a resource may 
perform or be used typically for one service at a time, and when in use is 
typically not available for any other use, or when engaged for some fiiture 
use is not available for engagement at the same time by another customer. 
For example, a person may be a resource, such as Sam the mechanic who 
does oil changes. When Sam is engaged in changing your oil, he cannot be 
engaged in changing my oil, and when Sam is committed to change my 
father's oil next Thursday at 2:00 PM to 2:30 PM he cannot be available to 
be engaged by another for that or another service in the same time interval. 
Further, an object may be a resource. For example, a service bay in which 
Sam the mechanic may perform oil changes, may also be considered a 
resource for purposes of embodiments of the present invention. Any 
supplier may provide a broad range of services utilizing individual resources. 
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In some cases the idea of a strict application of resources may be 
loosely enforced. For example, under some conditions, overbooking may be 
practiced. This would be done in situations of a supplier having a relatively 
large number of resources, and a clear history of no-shows. Such controlled 
overbooking is a function of yield-management, which is a service of the 
system to certain registered suppliers under controlled circumstances. In 
other cases, it is conceivable that some resources may be capable of multi- 
tasking. It is well-known, for example, that a hairdresser may be working 
with one customer while another is under a dryer, and so on. There are 
many other possibilities of multi-tasking in service industries, and the system 
of the invention accommodates this concept. 

Every resource has specific capabilities and uses, and these 
capabilities are recorded as a separate data structure 45. Each resource 
capability 45 is tagged in a preferred embodiment with the resource ED and 
supplier service ID, and is characterized in the data structure by one or more 
of availability, duration, cost, duration max, duration min, duration interval, 
and perhaps a textual description. A single resource, it should be noted, may 
have, if a person, a relatively wide range in skill set, and may therefore be 
capable of performing a relatively broad range of services. A resource 
capability represents one such skill of such a resource. 

Data structure 47 represents supplier services. A supplier service is 
defined as a service that is provided by one or more resources associated 
with a particular supplier. An example is an oil change that may be provided 
by Sam the mechanic, Supplier services will in many cases be instances of 
global services (or simply "services"), meaning that an oil change may be 
provided by resources associated with several different suppliers. In other 
instances a supplier service may be specific to a single supplier, and therefore 
proprietary. Whether a supplier service is an instance of a generic service or 
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specific to the supplier is determined by a servicelD associated with the 
supplier service. Note that a service, however specific, is not a reservable, 
but merely a description of actions that may be performed with and by 
resources for a customer. 

Another data structure, labeled service 49, represents the global 
services defined by the hosting enterprise. These services are always global, 
such as dinner, an oil change, or a haircut. A particular use of the global 
service data structure is in classifying services offered by suppliers to become 
inventory as reservables, so that the customer may readily search for 
available service inventory across suppliers. These service definitions remain 
fixed over relatively long periods in the system, but are not invariable, as the 
hosting enterprise will rely on the suppliers to further define existing services 
and even to invent new services from time to time. 

Yet another data structure 51, labeled vertical, is a vertical map, 
which identifies an industry category of services that are identical or very 
nearly identical. Tagging services with a vertical key is advantageous in 
limiting searches made, for example, on behalf of customers looking for 
certain kinds of services, generally provided by similar types of businesses. 
Another data structure 53, labeled vertical service map, combines service ID 
from structure 49 with the vertical key from structure 5 1 . 

Data structure 55 labeled supplier login, is a data structure specifying 
the format for login accounts of contracting suppliers. A data structure 57 
identifies support persons, such as knowledge workers, who may be 
authorized to enter and amend various information in the database. Another 
data structure 59, labeled supplier/customer profile, is a structure allowing 
the hosting enterprise to store and access information about customers that 
is specific to particular suppliers and which may be used to oflfer those 
customer priority service, discounts, special pricing, and so forth at those 
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suppliers. In the exchange model this data structure may also profile 
suppliers, and many services made possible by the unique aspects of the 
present invention depend upon information developed on both customers 
and suppliers and stored as profile information. 

Data structure 61, labeled engagements, represents engagements 
made by customers against reservables. Each reservation data record is 
enhanced by information completely identifying the engagement, such as 
Customer ID, resource ID, supplier service ID, start time, and end fime, and 
other information such as properties, party name, contact phone, and special 
requests. It will be apparent to the skilled artisan that not all of the 
information is strictly required, and in some cases other information may be 
required. 

Data structure 63 identifies to some extent each customer transacting 
with the exchange or with the single host of the service. This data structure 
includes information such as Ml name, given name, surname, nickname or 
alias, phone number, region key, login name, e-mail address, and in some 
cases other information. Structure 65 stores details of customer credit cards 
for charging against reservations made. Credit card information includes 
such as nickname, card number, expiration date, full name, customer ID, and 
address ID. 

Data structure 67 is for defining geographic regions in which services 
may be offered. It will be apparent to the skilled artisan that there is a broad 
variety of ways regions may be structured. In general regions in preferred 
embodiments of the present invention are structured reasonably for customer 
physical access to services. Data structure 69, labeled customer address, is 
for storing customer addresses, including at least street address, city, state or 
province, country code, postal code, and contact phone. Regional 
compartmentalization is very usefijl for efficiency purposes in many aspects 
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of the present invention. Typically, for example, a person (customer) 
shopping for a new muffler will want to transact with a supplier in the same 
town or general area as his/her home. This is not a strict limitation, 
however, because travelers may certainly wish to engage services along the 
routes of their travel, which may be extensive and global in nature. 

Data structure 71, labeled engagement reminder, stores data entities 
relative to engagements, and is provided to generate reminders (alerts) for 
customers of contracts (engagements) made to use services of suppliers in 
the exchange, or of the supplier in the single-host model Reminders may 
take the form of an email, an automated phone message, a fax, a pager 
message, and so on. Information includes such as reservation ID, customer 
ID, reminder time, and type. Reminders may be escalatory in nature as well, 
with repeat reminders spaced more closely and expressed with increasing 
urgency. 

The interconnecting arrows in Fig. 2 indicate interrelationships 
between the various data types and structures. Given the set of data 
stnjctures described with reference to Fig. 2, and suitable control functions 
and software described in enabling detail below, reservables are created 
(instantiated) in an ongoing fashion from unions and intersections of other 
data entities, customers may be efficiently and quickly matched with 
resources associated with contracting suppliers, and a variety of pre-and post 
reservation services may also be provided. It should be remembered, as 
well, as described above, that in some cases engagements may be made by 
customers with specific suppliers, and in some cases engagements may be 
contracted between a customer and the enterprise hosting the service 
exchange in an embodiment of the invention. In the latter case, the 
engagement is supplier-independent, and the enterprise hosting the exchange 
has latitude in specifying a supplier after an engagement is contracted with 
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the customer. Supplier-independent reservables and engagements are not 
denizens of single-host systems. 

In some cases, after an engagement is made, the consummation is left 
up to the supplier and customer. In other cases, however, the system, 
having detailed knowledge of all engagements, may offer and provide alert 
services, reminding customers of engagements. Such reminders can take a 
variety of forms, such as e-mail, automatic facsimile, telephone reminder, 
pager service, and so forth. Reminders and alerts may also be provided on 
an escalatory basis, so that a customer may be reminded of an engagement at 
one point in time, and then again at a time closer to the scheduled time of the ., 
engagement. 

Inventory Development 

As has been described in some detail above, the system of the present 
invention in a preferred em.bodiment comprises an exchange wherein 
customers may contract for services represented as reservable entities 
associated with specific suppliers, and in other embodiments in a supplier- 
independent manner. Reservables in the system are relatively rigidly defined 
and are calculated regularly from other data in the system to become 
reservable data structures in a time-based inventory. It is, of course, 
necessary to develop the inventory to have anything to sell to customers. 
And, since the reservables are fiinctions of service definitions, suppliers, 
resources, resource capabilities, and the like, these entities must be generated 
to develop reservable inventory. 

In a preferred embodiment, considering the multiple-supplier 
exchange model, there are a variety of different ways in which business 
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enterprises which wish to participate may do so. One method provided by 
the system of invention is through a browser interface. Fig. 3 is a schematic 
drawn from Fig. 1 of supplier communication with the system for creating a 
suppher relationship with system, and for such other tasks as defining and 
posting reservables with the system. In this arrangement a suppher may 
interact with the system on server 23 by means of PC 14 at supplier station 
12, establishing connection to the Internet 3 1 via ISP 18. The skilled artisan 
will be aware, again, that the schematic is representative of all of the 
conventional means by which a supplier may accomplish Internet connection. 

In one embodiment interaction by a supplier with the exchange- 
model system is via a conventional browser, which is represented in Fig. 3 by 
software 73. In the supplier interaction server 23 provides an interactive 
interface by virtue of software 29. In this environment the interactive 
interface may be a Web page, the Web page having interactive 
communication input mechanisms whereby the potential supplier may 
become familiar with the requirements of the system, and may provide 
needed information to become a registered supplier. In other embodiments 
supplier interaction with the system may take place in other ways, such as, 
for example, by mail or by telephone, such as through a telephony call 
center, wherein the customer may interact in some cases with live agents, 
and in other cases with automated interactive voice response (IVR) systems. 

Referring again to Fig. 2, there are a number of data structures that 
relate directly to suppliers. For example, structure 41 labeled suppliers, 
structure 55 labeled supplier login, service .49, supplier service 47, resource 
43, resource capability 45, and reservable 39. In the interaction represented 
by the arrangement of Fig. 3 a suppher may structure a contractual 
relationship with the system, and provide all of the information needed for 
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populating the data entities that the system needs to periodically instantiate 
reservables from the other data structures. 

No attempt is made here to illustrate a design for a graphical, 
interactive interface, because the mechanisms of such interactive interfaces 
are notoriously well-known in the art. Instead, the process of the supplier 
interaction with the system is described below in some detail. 

A first step in a supplier relationship in the exchange model is for the 
supplier to register with the system. This registration is a process of the 
supplier providing information to the system, and the system validating and 
recording the information. Referring again now to Fig. 2, this first step in 
registration is associated with data structures 41, labeled suppliers, and 
supplier login 55. In the process of supplier registration a potential supplier 
is asked to provide identification information such as full company name, at 
least one address, city, state, state or province, a country code, a city code, 
postal code, and perhaps various other information. The system may, for 
example, require background information such as financial health, banking 
information, and such things as maps and the like which may be needed for 
customers to take advantage of offered services. 

Once a suppher is registered with the system, that suppUer is 
assigned (or may choose) a supplier name and a password, which typically 
become a part of data structure 55 labeled supplier login. 

Once a supplier is registered with the system, and the enterprise 
hosting the system has validated and authenticated the supplier, the suppher 
becomes a part of the system. It will be appreciated that, once a supplier is 
registered, it will be necessary to perform regular and periodic updates, both 
from the host system's side, and from the supplier's side. 

It is now necessary to define what the supplier can and will supply, 
and this definition can take place quite neatly without creating a reservable. 
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An important ingredient in defining supplier services is, referring again to ' 
Fig. 2, is data structure 49, labeled service. Data structure 49 is typically a 
global service definition provided solely by the system. There may be a 
relatively large number of global services 49 defined by the system. These 
define many kinds of services that may be offered eventually as reservables 
by the system in a completely supplier-independent manner, and also serve to 
guide suppUers in defining the kinds of services they may offer through the 
system. These global services are services with definitions agreed to by the 
system and by individual and specific suppliers. For example, dinner for 
four, two in a hot tub, a man's haircut, or a hairstyhng session. In one aspect 
of the invention suppliers may agree to supply certain services according to 
the global service definition. In another aspect suppliers may define more 
proprietary services. In yet another aspect the system, having access to a 
number of suppliers, has the option of creating reservables, against 
potentially significant demand, without having those reservables associated 
with a specific supplier. These are the supplier-independent reservables 
described in some detail above. In this context it is helpful to contemplate 
that the kinds of services that businesses supply are not generated by the 
resources, but are pre-defined. That is, a particular business seeks to be a 
provider of a certain kind of services, and typically seeks and engages 
resources to be able to provide such services. 

Suppliers will further provide information to the system allowing the 
system to create reservables based on supplier-specific capabilities. 
Reservables that are specific to a particular supplier and resource can also be 
queried independent of that supplier and resource, by way of the inherent 
association of those reservables with a global service. Thus, the system may 
allow consumers to broadly search for engagements by scanning reservables 
that are independent of supplier or which are actually specific to suppUers, or 
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potentially both types of reservables, without necessarily exposing this detail 
to the end user. This includes data structure 43 of Fig, 2, labeled resource. 
A beauty shop, for example, may have four hairdressers, each of which may 
be entered in the system as a resource. A resource is listed with a name, 
availability, and perhaps a policy indication. A resource need not be a 
person, however, and may be an object or location. As an example, a 
resource may be a fully equipped hairdresser's station. Referring now to 
data structure 45, labeled resource capability, this data structure may be 
imputed based upon supplier resources. For example, the capability of 
hairdressers, as described above, may be limited by the availability of 
equipped stations, which are also resources. In other instances resource 
capabilities are entered by suppliers against explicitly known (and controlled) 
resources. 

Typically a supplier, in a preferred embodiment of the present 
invention will be prompted to provide additional information such as 
availability of resources with respect to time. It may be, for example, that a 
particular beauty shop as a supplier may have a schedule of being open only 
on weekdays, and never on weekends. It may also be true that certain 
hairdressers employed by the particular beauty shop are available only on 
certain days, or only at certain times of certain days. The same beauty shop 
may have service people trained to do manicures and pedicures as well, and 
these personnel may be available on different schedules than the hairdressers. 
Nevertheless, given a good definition of the supplier's standard hours of 
operation, all the resources of a supplier, and on the availability and 
capability (skills) of all the resources of that supplier, the system can create 
(instantiate) reservables associated with all of that particular supplier's 
resources and services over a specific time window. 



-30- 

Further, given the information provided as described above relative 
to the resources and availabilities of a supplier, the system may look to the 
supplier as a provider for supplier-independent reservables. It will be 
appreciated by the skilled artisan that there is very great variety of suppliers 
that may be represented in the system. Only a relatively few examples have 
been given. 

Referring again to Fig. 1, a generalized customer connection to the 
system is illustrated by customer station 1 1 connecting to Internet 3 1 
through high ISP 17. It was described above that this illustration is meant to 
represent all of the different ways that a customer might connect to the 
system in an embodiment of the invention. 

A customer, in preferred embodiment of the present invention, may 
connect and interact through a Web browser, interfacing to the system 
through Web pages provided by server 23. Again, as in the description of 
supplier interaction above, the mechanisms for such interaction are 
notoriously well-known, and it is not necessary or germane to the invention 
to describe such interactive interfaces in detail here. The interface the 
customer sees, however, will be very different than the interface seen by a 
supplier. The skilled artisan will appreciate that the customer interface may 
be nearly the same whether the system is of the single-supplier or the 
exchange model. 

There are a broad variety of ways reservables may be presented to 
potential customers. A customer may, in one embodiment, be presented 
with a graphical interface allowing the customer to select among different 
classes of services available. In an alternative embodiment a customer may 
simply be asked to specify an interest, which might be done through an 
editable field or a graphical element such as a drop-down menu, or an icon. 
There are many possibilities. It is simply required that the customer be able 
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to communicate an interest in a service to the system, and that the system, in 
turn, be able to present candidate reservables to the customer for 
consideration. The interactive interface necessarily also includes a way for 
the customer to negotiate in some instances, and to select from offered 
reservables, that is, make an engagement. It will be appreciated that, in 
general, the customer interface will be a bit simpler for the single host model 

In one aspect of the invention a customer may be what is known in 
other arts as a walk in. By a walk in in this sense, is meant a customer who 
visits the system on-line, but is previously unknown to the system, rather 
than a person who walks into one of the suppliers' premises. This is a 
customer previously unknown to the system, who is welcomed, and selects 
to make an engagement from the inventory of reservables presented by the 
system. In this case it is typically necessary for the system to validate the 
customer, at least to some extent. There are a number of ways this may be 
done. In one philosophy (and embodiment) the system may automatically 
validate a new customer for a first transaction, based on a more extended 
validation to be done in the interim between the engagement transaction and 
the actual delivery of the engaged reservable to the customer, which is, 
because of the nature of the time-based inventory, to be delivered at some 
time future to the engagement transaction. In this extended process, contact 
information will have been elicited from the customer, such as telephone, 
address, e-mail address, employment, credit card(s) (structure 65, Fig. 2), 
and so on; at least a subset of such information. The customer will have 
been entered in the database (structure 63, Fig. 2), at least temporarily. 

In the interim period, a subset of SW 29 (Fig, 3) does checkups on 
the customer information, and vahdates or invalidates the customer. In this 
process there may be automated or manual re-communication with the 
customer for further information or to clarify information. Once the 
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customer is validated a status change is made in the customer data structure 
for the specific customer. This status may indicate that the customer is no 
longer temporary, and later, after an engagement and payment history is 
established, may provide more granular status as to customer profile. This 
feature of the invention is enlarged upon in more detail below. 

In another aspect, a procedure may be established for customers to 
enter the system and be validated before making engagements, and an entry 
point to such a procedure is, in one embodiment, enabled through a 
hyperlink on.the interface page that a browsing potential customer 
encounters. 

Two distinctions are made. Firstly, the system distinguishes between 
known/authenticated ("online") customers and unknown/unauthenticated 
("offline") customers - a suppUer may only want to accept reservations 
(engagements) from known/authenticated customers, while another may not 
require authentication. Note that the credential required for authentication 
may vary, as mentioned above in the description of customer validation, and 
can be configured by supplier. One supplier might require the email address 
of the customer have been validated, for instance, while another also requires 
a valid credit card. The system handles both types of customers and 
suppliers, and remembers which customers have (not) been authenticated. 
Secondly, real walk-ins may be directly visiting a supplier, and more 
generally fall into the category of engagements entered into the system by 
the supplier on that customer's behalf Again, the system is able to 
automatically determine if a customer is known and authenticated and 
establishes the appropriate relationship between the new engagement and the 
online customer - or, if the customer is not known, associates the 
engagement with an offline customer (which may include name and other ■ 
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contact info but for whatever reason is not authenticated. There may not be 
sufficient time for this if the customer is at the business' premises. 

The notion of customer listing, validation, and authentication is a 
very important ingredient in the present invention. The present system, both 
for suppliers in the exchange model, and in the single-host model, has a real 
capability to become a broad-based tool for business strategy and 
management, and knowledge of customers is a critical ingredient. Many 
services bearing on strategy, management, yield and the like are described 
ftirther below, and most bear to some extent on customer profile. 

One of the bits of information that the system derives from customer 
interaction is regional inclusion. Typically the system, depending on 
geographic extent, will operate at least partly through regional indexing. 
From each customer's address or postal code, for example, the system may 
classify the customer as domiciled within one or another system-defined 
region. The customer's region may have important effect in presentation of 
reservables to any particular customer for engagement transaction. The 
regional classification apphes also to suppliers, and through supplier region 
to a region index for certain reservables in the system. It will be appreciated 
by the skilled artisan that not all transactions by customers for services from 
suppliers will be for services to be performed in a region common to both 
the supplier and the customer. In many cases this will be so, but there is also 
the case of, for example, the business traveler preparing an itinerary for a 
trip. This customer may be traveling from his/her home base in California 
for a series of meetings in New York City, for example, and may wish to 
contract for services while in New York city. This sort of more global, and 
even International matching of services to customers can be much more 
sophisticated than these simple examples, and is one of the premier 
advantages of such a system. A customer authenticated by the system of the 
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invention may then be authenticated to a broad range of suppUers on a global 
scale. Suppliers may be similarly qualified for the confidence of customers. 

Database Implementation and XML 

There is much more to be disclosed and taught in the present 
specification relative to inventory development, presentation, transaction, 
and the like, and more such detail is provided below. The fiarther 
description, however, will benefit from a discussion at this point of database 
implementation, of the nature of data structures, and particularly of time- 
related entities, which may be either time spans or time intervals. In a 
preferred embodiment of the present invention certain database objects may 
be expressed in Extensible Markup Language (XML), which is a network- 
related computer language notoriously well-known in the art. There are a 
number of good reference publications available to the skilled artisan 
covering the subject of XML, as well as a wealth of information available on 
the Internet on the subject. The skilled artisan will have no difficulty 
reviewing the details of XML. 

Time-span Treatment and Time-span Algebra 

Database technology is a well-developed science in the computer 
arts, and much is available in the art as to how data entities may be stored, 
retrieved, and manipulated. For example, at a granular level, data in a digital 
repository is typically stored as binary strings (words in addressed locations). 
The size of a data repository may then be defined as a specific address space. 
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At a higher level, data entities may be expressed as JAVA objects in a 
standardized manner well-known in the art, and certain functions lend 
themselves to such definition and expression. The present invention makes 
use of these and other known protocols and techniques in several aspects. 

The present inventors have noted that there are particular 
advantages, in such as data transmission, for example, in representing certain 
entities as XML strings. Among these entities are the records described 
above that may be expressed as potentially infinite time spans. In a preferred 
embodiment many such records may be expressed for certain purposes as 
XML strings. The system, for example, converts customer requests to XML 
expressions, and also expresses many database entities at some point as 
XML strings. The skilled artisan will recognize that the software of the 
invention may covert between XML and other sorts of expressions. 

A time-span in a preferred embodiment of the present invention 
represents a potentially infinite set of time intervals, the time intervals 
defined as half open so as to not logically overlap. 

Reservables, and other time-dependent records, in a preferred 
embodiment of the present invention, are manipulated in context of a set 
theory of time-span algebra, described in some detail below. This algebra is 
used for several functions in operation of the system of the invention in 
several embodiments, such as to determine, for example, if a reservable 
intersects with and contains (completely overlaps in time) a customer 
reservation (engagement) request, indicating that the reservable is a 
candidate to fulfill the request. 

Time-spans may be established and used for any of several kinds of 
data records that are time-based. Fig. 4a is a schematic of some relatively 
simple time-spans according to a preferred embodiment of the present 
invention, that may expressed as time-spans in XML format. In Fig. 4a time- 
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spans with individual time intervals are shown for resources 75, reservables 
77, and engagements 79. 

Time-span 75 for resources shows two time intervals 8 1 and 83 for a 
resource Bimny, who, in this embodiment is a worker in a hair and nail 
emporium. Bunny is shown as being available from 8:00am to 1 2:00pm and 
from 1 :00pm to 5:00pm on a daily basis. This availability for a resource 
such as Bunny is stored in XML as a database entity in a manner to be 
described in more detail below, wherein one record may describe availability 
for Bunny over a potentially infinite time span in a relatively simple 
expression that describes the two time intervals shown. 

Time-span 76 in Fig. 4a for reseivables illustrates two time intervals 
86 and 90. In interval 86 Bunny is illustrated as being available for haircuts, 
manicures, washes, and sets from 8:00 AM to 12:00PM. Time interval 90 
illustrates Bunny as available for the same services also froml :00 PM until 
5:00 PM. This reservable may be represented as an XML expression. 
Certain time-varying properties of the resource and service may also be 
associated with reservables and captured in the XML expression, such as 
service cost if the supplier is implementing dynamic pricing (explained in 
detail below). The formula for time-varying properties are defined in the 
resource and/or resource capability, and regularly updated (e.g., nightly) 
across all generated reservables to ensure the values are accurate. This 
allows rapid search by time-varying properties, like price, without having to 
recalculate the current price for each reservable for each search. Even 
though time-spans by definition may be infinite in extent, reservables are 
never infinite. If they were, and they are the inventory in the system 
described and taught herein, the database to store them would also be 
potentially infinite. Reservables always have a definite start and end point in 
real time. The skilled artisan will recognize that there will be, in a typical 
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system practicing the present invention in any of its several aspects, very 
many more reservables than those illustrated in Fig. 4; but the few shown are 
considered by the inventors to be adequate for description. In another 
embodiment, the compound reservable for Bunny might be represented as 
four separate reservables, one for Bunny haircuts, one for Bunny manicures, 
and one for Bunny washes, and one for Bunny sets. 

Time-span 79 in Fig. 4a illustrates engagements in the system. 
Engagements are the recorded reservation transactions made by the system 
on behalf of customers. In the embodiment represented by Fig. 4a, as a 
simpHfied example, a customer in conmnunication with the system may be 
seeking a haircut and may specify 10:00 AM as a preferred time. The 
system, consulting vertical and* regional mapping presents the best matches 
of reservables to the customer's request. 

In a preferred embodiment a unique time-span algebra described 
more ftilly below is employed by the system in searching, selecting, and 
presenting, and also in instantiating reservables from other database entities. 
In this algebra, the customers input is expressed in XML terms, reservables 
from the database are expressed in XML terms, and the algebra is employed 
to find intersections with reservables. 

The customer (G. Smith) in the end selects a haircut fi^om Bunny 
for 10:00 AM on Tuesday (day not indicated in Fig. 4a), resulting in 
engagement 95. The system records the engagement transaction, and stores 
the engagement (reservation). A range of date is associated with the 
engagement, such as the customer ID, the supplier ID, the resource ID, the 
day, the time, and so forth. 

There are a number of other services which may be provided by the 
system following the transaction initiated by a customer selecting a service. 
Among them are informing the supplier (and the resource through the 
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supplier) of the transaction, and alerting the customer at some time before 
the service is to be performed. There may also be various accounting 
services as a result of pre-arrangement between the system and either or 
both of the supplier and the customer. A second engagement 97 for Bunny 
at 1 1 :00 AM for a haircut for D. Jones is also indicated in Fig. 4a. 

An important feature in this embodiment is that services that Bunny 
may perform at any time during a specific time widow within which the 
system is working may be (before an engagement is made) represented by a 
single XML expression. The first engagement made necessarily breaks the 
time span of a reservable into two pieces, each of which may be represented 
by a separate XML expression. After an engagement transaction the system 
simply represent the two unbroken pieces of the original timeline by two new 
XML expressions as reservables. The skilled artisan will realize that the 
reservables are not necessarily stored in the database as XML expressions, 
but in forms that may be converted in either direction. A second 
engagement 97 breaks one of the two reservables into, again two more 
reservables (now there are thj-ee). ThJs unique representation provides a 
very large inventory of engagable services (reservables) in a minimum 
representation, and keeps the number as small as possible as new 
engagements are made and recorded. 

Time-spans, in the preferred embodiment, are represented within a 
computational class hierarchy, according to object-oriented programming 
techniques. The.time-span classes, as described herein, represent a sequence 
of time intervals and the unique time-span algebra provided by the inventors 
provides mechanisms for compiling time span expressions and for 
manipulating and evaluating time span expressions. Time-span objects . 
(instances of the said classes) are eflFiciently stored in the database as XML 
strings, or in other forms, and can represent things like: when a service is 
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available, when a resource is available or when a supplier is available, as 
illustrated in Fig. 4a and as described above. 

Each time span is half open, that is it includes its start time but does 
not including its end time. This is usually represented as [start, finish) in set 
theory. The time spans can be based on a Gregorian calendar or on absolute 
time, but they are stored and manipulated without a time zone. The time 
zone is added only when time-spans are being "enumerated" to determine the 
actual time intervals they represent. Each instance of this class is immutable, 
allowing for caching of time space sequences. 

Fig. 4b represents an alternative embodiment in which reservables, 
such as 85, 87, 89, 91 and 93 are represented as discrete reservable units, 
rather than as time spans or intervals. In this implementation many more 
expressions are required in the database than in the embodiment described 
from Fig. 4a. In the embodiment represented by Fig. 4b the system simply 
removes a discrete reservable each time an engagement transaction is made. 
Each transaction therefore reduces the number of reservables in the 
database. 

The text language used to represent a time-span is based on XML, 
with the following syntax: 

<time-span:DA]LY fromHour=hh fromMinute=mm toHour=hh 
toMinute=mm/> 

This expression represents a daily, half open span from the given • 
hour and minute to the given hour and minute. For example. 
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<time-span:DAILY fromHour=15 toHour=17/> represents a 2 hour 
period from 3:00pm to but not including 5:00pm (half open). 

A full day is represented by a Daily whose fromHour and 
fromMinute are equal to its toHour and toMinute values. The minute fields 
are optional, and the hour should be denoted in 24 hour time, i.e. 1pm 
=> 13. Note that the span may include midnight by having the end time 
precede the start time. Valid hour values are "0" to "23 while the valid 
minute values are "0" to "59". 

<time-span:FIELD field=fF start=ss end=ee/> 

This expression represents a half open interval in units determined by 
ff, which is a text representation of the fields from the java.util.Calendar 
class, e:g. hour, or day_of_week. The starting value for that field is start, 
and end is the ending value for that field. The end value may be less than the 
start value, which means that any value not in the range of end+1 to start- 1 
will match. The start and end values can be either numeric or string 
values(i.e., "1" or "February" or "Feb"). The numeric values for the months 
range from 0 - 11 (jan - dec), while the numeric values for the day_of_week 
range from 1-7 (sunday - Saturday). 

These values are not case sensitive. If the start value is equal to the 
end value, the time span sequence represents the time-span from the start 
value to and including the end value. For example, a Field time-span from 
hour 13 to hour 13 represents the daily time-span from 1:00pm to but not 
including 2:00pm. 
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<time-span:BETWEENMILLIS startTime=mmmmmminmm 
endTime=mmnHnrnniminm/> 

represents a time-span from the given absolute time to the given absolute 
time. Note that the time may be given a decimal number of milliseconds from 
the Java epoch, or it can be given as a standard format date representation, 
always including a time zone parameter. The format of the date is "yyyy.M.d 
HH:mm:ss.SSS z", i.e. "1999.5.11 12:11:12:322 PST". 

When specifying the time in standard date format, the string is 
enclosed in double quotes, i.e. <time-span:between milUs 
startTime="1999.5.11 12:1 1:12:322 PST" endTime:"1999.5. 20 4:40:35.000 
PST"> 

<time-span:CAL year=yyyy month=m day_of_month=d hour_of_day=h 
minute=m second=s millisecond=m/> 

represents a single point in time (which has no duration). Except for the 
"year" field, which is required, any subset of the above fields may be used to 
specify the date. Unspecified fields are given the Calendar's default values, 
which are typically the lowest possible value for that field (Month =jan, hour 
= 1, etc). The values for the field "month" can be either numeric or string 
values (i.e. "Feb", or "Feburary" or "1"), while the rest of the fields must be 
numeric values (those numeric values that are valid for these fields according 
to the java.util.Calendar class). 

<time-span:DURATION field=ff distance=dd> <CAL> </time- 
span:DURATION> 
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represents a time-span beginning from CAL (a CAL time-span described 
above) and ending a time distance (in units of field) away. The field, fF, is a 
text representation of the fields from java.util. Calendar (i.e. hour, 
day_of_week,..), while the distance is a numeric value that is within the 
particular field's valid range. (i,e "1" - "7" for the day_of_week field). The 
duration time-span will add in the units of the specified field, and not 
necessarily the absolute time-duration represented by that field. For example, 
if one adds a month to Oct 30, the result would be Nov 3 1 (or a change of 
3 1 days). However, if one adds a month to Nov 3 1, the result would be Dec 
30 (or a change of 30 days). 

<time-span;BETWEENCALS> <CAL> <CAL> </time- 
span:BETWEENCALS> 

represents a time-span ranging from the first encountered calendar tag to the 
second calendar tag. 

s 

<time-span: SMEAR field=fF distance=v> <TS> </time-span: SMEAR> 

This is an operation that extends either the start or beginning of the 
time-span, TS, by the specified distance. The distance is in units of field. 

<time-span:TRANSLATE field=fr distance=v> <TS> </time- 
span:TRANSLATE> 

represents an operation that translates the enclosed time-span, TS, by the 
time distance, distance. The time distance is in units of field ff (i.e. month, 
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year, day_of_week, ..). Distance can be either a positive or negative 
numeric value. The positive value translates the time-span forward in time, 
while the negative value translates the time-span backwards in time. 

<time-span:UNION> <TS1> <TS1> ... <TSn></time-span:UNION> 

This is an operation that returns the time-span that is the union of the 
enclosed n time-spans. 

<time-span:INTERSECT> <TS1> <TS2> ... <TSn></time- 
span:rNTERSECT> 

This is an operation that returns the time-span that is the intersect of 
the enclosed n time-spans. 

<time-span:SUBTRACT> <TS> <TS> </time-span:SUBTRACT> 

This is an operation that subtracts the second time span, the minuend, 
from the first time-span, the subtrahend. 

<time-span:INVERSE> <TS> </time-span:rNVERSE> 

This is the inverse of its single argument time span. 

<time-span:SIZEFILTER duration=d> <TS> </time-span:SIZEFILTER> 

This operation filters out all spans of TS that are smaller than the 
value of duration. Duration is in units of milliseconds. 
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<time-span:REFERENCE ref=name> 

represents a reference to another time span object defined somewhere else. 
The context should be implicit in the place where this object is being read in. 

<time-span:EMPTY/> 

represents the empty set (no time). 
<time-span;UNIVERSE/> 

represents all time fi-om the theoretical beginning to ending. 
Time Window 

Another characteristic of the system of the invention in a preferred 
embodiment is the fact of a moving window of active data entities such as 
reservables and engagements. As described above, the time span by 
definition, and by construction in XML, is theoretically infinite in extent. 
For purposes of finite operations, a time window is imposed upon the 
database in a preferred embodiment, and operations are typically confined to 
the time window. This widow is theoretically of arbitrary extent, as well, 
and serves to limit the size of the data repository wherein reservables and 
some other data structures are stored and to therefore limit the 
computational cost of operations thereupon. 

Fig. 5 is an illustration of a six-week time window 104 from today 
through a point six weeks hence showing reservables 100 and engagements 
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102 in the database. The reservables portion within the time window is the 
portion of the database that is searched to determine matches to a customer's 
request for service. The reservables 100 are created from resources 
available (instantiated), and in some cases defined against future expected 
resources, and are implemented in the database within the window at any 
particular time. Because each time-based reservable entity is a positive 
expression this implementation of a time window serves to limit the size of 
the active database, that is, the number of entities that have to be stored and 
searched. The skilled artisan will be aware, and it is clear from Fig. 2, that 
there are also many data entities in the database that are not time-based, such 
as supplier ID, service maps, and the like, but these entities are all finite by 
definition, and a time window is not necessary to limit their number. 

In a preferred embodiment, referring now to Fig. 2, reservables are 
instantiated in the active time window on a periodic basis. The process is by 
time-span algebra, wherein unions and intersections of other entities 
represented in XML are determined to form reservables. A reservable may 
be thought of as an integration of a number of database entities, and is in fact 
generated by time span algebra operating on these data entities. Vertical 
categories (verticals 51) define service categories as generic to different 
classes of enterprise, such as medical, automotive, and so forth. These 
definitions serve to define specific services 49, which may be amended for 
specific suppliers to define supplier services 47, which now has the attributes 
of a supplier, the service definition, the vertical to which it belongs, cost, and 
duration. A supplier brings resources, such as Bunny and Melissa, for 
example, who have certain skills and availability expressed as time-spans. A 
union of these produces resource capabilities, which is now to the level of a 
Melissa haircut, for example. 
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Time-span algebra as defined herein, and other data manipulations 
serve to update the data available to the system on a regular basis, then, at 
selected points in time, reservables are instantiated from these other data 
entities, and projected over the active time window of the system. It will be 
apparent to the skilled artisan that at the time of instantiating reservables, 
only the changes in data entities since the time of the last instantiation have 
to be considered. 

Engagements are created in the database necessarily in real time, that 
is, at the time of the trailing moving edge of the time window, which is 
present time. However, since an engagement is a contract between a 
supplier and a customer for the supplier to provide a service at a future time 
and date, and for the customer to appear to take delivery of the service, and 
since there is typically a specific time start and end point for the engagement, 
engagements may be (and are in this embodiment) projected forward into the 
time widow as shown in Fig. 5. 

In a preferred embodiment the system operates by moving the time 
window forward day by day, or on some other schedule. The ^yindow may 
be moved on a daily basis in some embodiments, and on a different schedule 
in others, or may be updated (reservables instantiated from other entities) on 
a continuous basis. There are a variety of calculations that are made in this 
process. For example, the day that passes and becomes yesterday no longer 
has reservables or engagements. One cannot engage a service to be 
performed in time past. At the same time, reservables are instantiated in the 
database for the time window when the window moves forward by a day, for 
example to the position shown by window 106 in Fig. 5. 

In another aspect of the invention, the system, in addition to creating 
and recording engagements in the time window, also does accounting 
services relative to engagements. This process may begin in some cases at 
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the point of engagement, because, in the system of the invention, in many 
cases the inventory may be marketed, sold, and accounted for by the x 
enterprise hosting the system, rather than by individual suppliers. In other 
cases the beginning of such an accounting process may be delayed 
somewhat, but typically will start between the time the engagement is made 
and the time the engagement is consummated, that is, the service is actually 
delivered to the customer. In one case, the hosting enterprise contracts with 
suppliers for services, and becomes a service reseller, accounting for 
transactions with customers, and paying suppliers for services in bulk units. 
In many cases the accounting system in all of its various aspects, is separate 
from the database shown in Fig. 2, but cooperates and communicates with 
the database of Fig. 2 in performing the accounting and transactional 
fijnctions. 

Returning again to Fig. 5, the typical situation is that matching 
customer's requests to reservables, and recording of engagements all occurs 
within time window 104/106. There are, however, situations wherein a 
request for service may be beyond the time window, for example. There is 
also the situation wherein demand is large, and waiting lists may be created. 
In either of these cases, and perhaps others, operations may be made outside 
the moving time window, in which case reservables are generated 
dynamically by the system, now also necessarily accounting for existing 
reservations outside the time window, to determine service availability. 

System Operations 

Given the set of time-span expressions and the time span functions 
described above, a unique system and method for marketing and selling time- 
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related inventory to customers is provided. In this system, inventory of 
reservable services (reservables) is semi-continuously created, and through 
presentation to customers seeking services, the reservables are matched with 
customer's requests, and after typically some negotiation, engagements are 
created, which are eventually consummated, at least to a great extent. By 
the unique nature of the system in embodiments of the invention, there is a 
unique variety in the transaction processes that may be accomplished. 

Fig. 6 is a process flow diagram illustrating one exemplary process 
flow in an embodiment of the invention. At step 99 a customer enters the 
system through an interface as described above. In the process, if the 
customer is known to the system, the system consults the database and 
identifies the customer at step 101. If the customer is new to the system the 
customer is prompted for certain information, before being entered to the 
system. In some cases the customer may not be allowed to enter the system. 

In the initial customer interaction the system determines, as well, the 
customer location, also at step 101 . This is an important criteria in most 
cases, because it is only the inventory local to the customer that may be of 
interest to the customer. 

At step 103 the customer indicates his/her preference(s). The system 
consults a vertical map and regional keys (see Fig. 2) in step 105, and thus 
limits database interaction (searching) to a small portion of the stored data 
records, being those records that will be of interest to the customer. This 
ability to refine the search is of considerable importance. In some cases, as 
alluded to above, there will be no strict confinement to a specific region. A 
customer may be seeking services, for example, specifically in a region 
remote from the customer's home or business. These cases are handled by 
the nature of the customer requests, and by interaction by the system with 
the customer. 
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At step 109 the system, having performed the limited search, presents 
qualified reservables for the customer's selection. In this step, there may be 
incremental interaction between the system and the customer, and additional 
search steps as a result. At step 107 the customer makes a selection, and at 
step 1 1 1 the system creates a new engagement. The engagement is entered 
into the database, and becomes an object upon which the system may 
continue to act (1 13) until at least the time the engagement is consummated 
at a future date. 

As described to some extent above, after making an engagement, the 
system must amend the reservables database. The reservable engaged is no 
longer available. In the case of discrete reservables (alternative embodiment) 
the system simply removes the reservable which was engaged by the 
customer. In the case of time-line reservables, the system amends the 
reservables appropriately to illustrate and offer the service not engaged in 
previous transactions. 

In this process, the localization is noi quite as simple as limiting all 
qualified reservables to a geographic region centered on the customer's 
address, for example, although this may often be the case. In many cases, 
the customer may specify a region remote from his/her locality. For 
example, a customer may be creating an itinerary, and wish to engage 
services in a faraway locale for certain dates. A customer might also engage . 
services for another, such as a friend or a family member, in a different 
locale, and interface tools are provided by the system for these purposes. 



Dynamic Pricing 
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Provision is made in the system for a number of novel functions. For 
example, pricing of time-based inventory may be dynamic. As a simple 
example of dynamic pricing of time-based inventory in this context, consider 
the six-week time window (exemplary), and the fact that all transactions with 
a customer occur now. The enterprise hosting the system may contract with 
suppliers for one price, say a fixed price over the time window period, but 
market the inventory at other prices. In the dynamic context there may be a 
relatively higher price for engagements within one to three days, a lesser 
price from three days to one week, and a sliding scale beyond one week, 
with engagements made six weeks out at a minimum price. There are many 
possibilities for time-based dynamic pricing. In another example, dynamic 
pricing may also be based on such as inventory level Supply and demand 
becomes freely applicable, with the relative supply and the relative demand 
determining pricing, and mechanisms may be included for applying 
intelligence to pricing based on transaction history stored for a particular 
customer. 

In another aspect, pricing may be varied by day of the week, time-of- 
day, or time-of the month or year, encouraging potential customers to 
purchase offered reservables at times that statistically support a lower level 
of purchase activity. 

In yet another aspect pricing may be entirely flexible, as in any one of 
several types of auctions. Such an auction may be a straight auction, 
wherein the customer is provided interface tools for bidding on available 
time-based inventory. The controller of the auction may be the enterprise 
hosting the system of the invention, having pre-contracted for reservables. 
In other cases the hosting enterprise may act as an auctioneer for individual 
suppliers, who control their own pricing. 
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In another aspect time-based inventory may be offered by reverse 
auction, wherein customers list services they wish to engage, the system 
matches the Hsted services with reservables, and individual suppliers respond 
by bidding to provide the best price. 

In yet another aspect time-based inventory may be subject to Dutch 
auction. Dutch Auctions are a special auction format where a supplier has 
multiple, identical services he or she wishes to sell. The seller specifies the 
minimum price (the starting bid) and the number of reservables available. 
Bidders bid at or above that minimum for the quantity they are interested in 
purchasing. At the close of the auction, the highest bidders purchase the 
items at the lowest successful bid. 

Also, the enterprise hosting the system may enable customers to 
aggregate to increase their buying power. For instance, customers could 
place group reservations (engagements) at a volume discount, and the 
supplier(s) involved might service this reservation individually or all 
together. There are many alternative scenarios for dynamic pricing. 

Special Circumstances in Transaction Matching 

The unique model of the system of the present invention allows a 
number of services to be offered to potential customers that may not 
otherwise be available. For example, there are, in a preferred embodiment, 
automated wait lists for services that may not be currently available. Similar 
lists may be offered for highly desirable services, such as a table on a 
preferred evening at a desirable restaurant. In other cases, there may be a 
market for re-selling no-shows. For an upscale establishment, for example, 
the service of the invention may maintain a waiting list of people who are 
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willing to respond quickly to, for example, take a table at a restaurant in 
place of a party that cancels or simply does not show up. The time frame 
differs for late and no-show, as well, and presents opportunities for dynamic 
pricing. In one embodiment the system of the invention may provide a 
service wherein customers agree to cancel within a time frame prior to the 
engagement time, or forfeit the price of the service, or at least a portion of 
the price of the service. In this situation, the broken engagement can still be 
resold if there is enough time. 

In any of these cases engaging customers are notified when the 
service becomes available, and auction aspects may also have interplay. In 
some cases subscribing customers may be given preference according to 
purchase history and the like. In some embodiments the customer may 
specify the mode of contact preferred for alert that a reservable has become 
available, such as by telephone, facsimile, pager, and the like; or a 
combination of alert modes. In another embodiment reservables may be 
bundled, and the bundle treated and marketed as an entity. 

Many such services, including automated yield management are 
services that may be supplied by the hosting enterprise to suppliers, and 
there are, in a preferred embodiment, pricing models for providing such 
services to supplier businesses. 

Service Coloring and Shading According to Profile, History and 
Preference 



As described above, suppliers are registered with and known to the 
hosting enterprise, and the host may make a broad variety of contractual 
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relationships with suppliers. There will be, in many instances of the system, 
a single supplier, such as instances where the system is configured for one 
enterprise. Similarly, it was described above that customers, once they enter 
and use the system, become known to the system. The system in one aspect 
keeps continuously updated records of all transactions, and makes updates to 
both supplier and customer history. Many special services to both suppliers 
and customers may be predicated on such historical record. A customer 
with an active and regular purchase record will, in some embodiments, be 
offered special breaks, coupons, and the like, and may also be given priority 
in certain situations; where inventory becomes relatively scarce for a time, 
for example. In some cases there may be special relationships between 
suppliers and customers, and joint profile and history records may be kept 
and used. Certain suppliers may wish to accord VIP status to certain 
customers, and to provide special advantages to such customers. 

In another aspect of the invention, for relatively scarce resources, the 
system may track engagements and demand; and in some cases customers 
holding engagements at an agreed-to price may be offered a takeback at a 
higher price, as the system will have a waiting customer willing to pay yet a 
higher price for the reservable. This service is also a part of yield 
management for certain subscribing suppliers. 

There are other opportunities that may be pursued in the system 
relative to profiling as well, such as customer ranking (VIP), and such 
ranking may be shared among suppliers in some embodiments. The same 
kinds of ranking may apply to suppliers. 

In another embodiment services are provided to customers enabling 
customers to barter and trade engagements, which may be viewed by 
customers as assets of variable value. The value of an engagement asset may 
be somewhat intrinsic, and also subject to customer taste. Opportunities 
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exist, for example, for customers to purchase engagements, and resell or 
barter. In one sense, engagements may be treated as commodities or stocks, 
and traded as such. 

The inventors are aware that the disclosure presented herein is a 
comprehensive disclosure, and the inventors believe that there are a 
relatively large number of inventions disclosed herein, some of which may be 
patentably distinct. The inventors have made an effort to present in this 
application only claims to a single patentably distinct invention. Other cases 
are or will be filed from this disclosure with other claim sets for examination. 

In addition to the above, it will be apparent to the skilled artisan that 
there are many alterations that may be made to the embodiments described 
above while remaining within the spirit and scope of the invention. The 
claims presented below should therefore be accorded the widest possible 
scope. 



